Best Practice Guide - Intra-day updates to a customer attributes table

Introduction

Alterian recognize the need for the campaign system to receive changes to attributes or preferences of known Customers from an external system, and the need for that to occur intra-day to enure those changes can drive personalization or campaign audiences.

This Best Practice section will cover two simple use cases of this type and how the Campaign Manager API can be used to achieve this.

Assumptions

• Familiarity with the Alterian Campaign Manager API is essential.
• Familiarity with Alterian Engine load strategies is required to ensure this process fits in with overnight load strategies.
• This functionality is aimed at lower volume attribute updates and does not replace existing overnight load strategies.
• Important considerations listed below have been viewed and considered for any API's to be used.

Important Considerations

• The Table and columns being updated must be created prior to commencing this process.
• The Table must contain a unique key and it is highly advisable to add the UniqueConstraint property to that key.
• This call will only update/insert records.
• New columns cannot be added via this method.
• This process will extend widths on TEXT/UNICODE columns to match incoming data.
• This is NOT a replacement for an overnight load to facilitate loading of the wider dataset. This process should be used only on tables where necessary.
• This feature is currently only available using the campaign API method as defined here.
• When using a Customer Attribute column in a campaign Audience, the audience refresh must be dynamic to poll for new contacts intra-day.
• Using this method for adding new rows can impact the Campaign Key table performance as previously mentioned. There are also implications on adding new campaign keys and with data quality, as well as the impact on the overnight load. This should be discussed with Alterian Professional Services before implementing.

DATA structure

Although this process can be used to update any table, it is advised that a specific Customer Attribute table be created for this purpose. A Customer table in the existing repository is often the Campaign Key table and as such can come under quite a heavy load, with segmentation, campaign activity and reporting all being run against it in unison. Using a separate Customer Attribute table, linked 1 - 1 to the existing Campaign Key table will avoid adding more concurrent processing to this busy table, and optimize Engines ability to update the values Intra-day.

Use cases

Use Case 1 - Personlization Based on Last Search.

A travel company has a weekly email campaign to its Customers. To add incentives based on current areas of interest, sections of the email are focused on holidays based on their last search. The requirement is to capture this value intra-day, rather than part of the standard overnight data load, to ensure it is timely and relevant. The holiday company website is tagged to capture the type of holiday last searched for by a known Customer, and this can be one of 5 values, Adventure, Ski, Beach, Weekend or Cruise. This tagging will create an event to be passed to the Alterian Campaign Manager API.

Use Case 2 - Loyalty Competition Sign UP in Journey campaign

The travel company has offered existing customers the chance to enter a competition to win a holiday of their choice. This competition entry is done on the website and this adds them to the audience of a campaign that coordinates the communications as part of the journey through the competition. The requirement is for this journey to start on the day of sign up. The website has been tagged to capture details for known Customers and create an event to pass to Alterian Campaign Manager API

Other Details

• A Customer Attribute Table has been created which is linked 1 - 1 with the Campaign Key table.
• This Customer Attribute table contains three columns, Cust ID, Last Holiday Search and Loyalty Comp. The table and both columns have been created by the Load Team to ensure they are of the correct data type.
• The Weekly email uses the Last Holiday Search column to drive personalization within the email.
• The Audience for the Competition Campaign uses the Loyalty Comp column as its audience inclusion criteria.
• The refresh frequency of the Audience for the Competition Campaign is set to "Always" in Campaign Manager or Dynamic in Campaign Designer to ensure the system polls for new audience members intra-day. This setting is not the default.
• Currently, CustID 13, has a Last Holiday Search value of Beach and is not entered into the Holiday competition

Using the QUEUEENGINETABLEUPSERT API

Use Case 1 - API Configuration using the LIve Example in the API Help, the functionality has been tested

.

Example of JSON string passed to the API

{

"DataSourceId":"101",

"FieldNames":["Cust ID","Last Holiday Search"],

"KeyFieldName":"Cust ID"

"TableNameEx":"[Demo].[Customer Attribute]",

"Token":"XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX",

"Values":[[13","Ski"]]

}

Use Case 1 - API Configuration using the LIve Example in the API Help, the functionality has been tested .

Example of JSON string passed to the API

{

"DataSourceId":"101",

"FieldNames":["Cust ID","Loyalty Comp"],

"KeyFieldName":"Cust ID"

"TableNameEx":"[Demo].[Customer Attribute]",

"Token":"XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX",

"Values":[[13","Y"]]

}

Although both example above give an update to a single column, multi-column updates are possible using the same API by simply adding to the configuration as follows:

• Best Practice Guides
• Audiences, Tracks, Events and Polling
• Campaign Approvals
• Conceptual Campaign Design
• Data Engineering in Campaign Manager and Engine
• Event Source Configuration and Processing
• iLoader - Strategies For Loading Data
• Implementing an Intra-Day Data Strategy
• Intra-Day updates to a Customer Attribute Table